I realized not long after 5.0.0 release that we could simply use incrementing IDs in VanillaBlocks/VanillaItems (in the same way that plugins have to),
and just generate constants for BlockTypeIds/ItemTypeIds from there. This reduces the number of manual needed to implement new blocks and items, since the autogen can be automated when modifying VanillaBlocks/VanillaItems.

Longer term, we should probably explore getting rid of these IDs altogether. I added them to ensure we had a way to compare item types without cloning items from VanillaBlocks/VanillaItems, but in practice this is likely just premature optimization thinking carried forwards from the old ID system, as pointed out by @jasonw4331.

For the duration of PM5 support, however, this will now have to be maintained, as we can't remove them before PM6.

this makes vanillaBlocks less ugly, and also removes a manual step when adding new blocks.

this stops the entire file from changing when adding new blocks.
the diff will instead look something like this:

@@ -713,7 +722,8 @@ final class BlockTypeIds{
        public const CHERRY_DOOR = self::CHERRY_STAIRS + 1;
        public const CHERRY_BUTTON = self::CHERRY_DOOR + 1;
        public const CHERRY_PRESSURE_PLATE = self::CHERRY_BUTTON + 1;
-       public const CHERRY_SIGN = self::CHERRY_PRESSURE_PLATE + 1;
+       public const CHERRY_TRAPDOOR = self::CHERRY_PRESSURE_PLATE + 1;
+       public const CHERRY_SIGN = self::CHERRY_TRAPDOOR + 1;
        public const CHERRY_WALL_SIGN = self::CHERRY_SIGN + 1;
        public const CAULDRON = self::CHERRY_WALL_SIGN + 1;
        public const WATER_CAULDRON = self::CAULDRON + 1;

we don't actually care about the specific values, only whether all the blocks and their states have been correctly registered.
I'd prefer to track all of the state data permutations, but the APIs for that are private, so tracking the number of permutations will have to suffice (this should be good enough to detect bugs anyway, and also takes way less space).

we can't rely on BlockTypeIds to look up the ID name if the type IDs aren't consistent to begin with...
I don't like using VanillaBlocks for this (we might have multiple source registries in the future, e.g. if we decide to pull the education edition blocks into their own registry), but it doesn't seem like we have a choice.
For now this is valid anyway.

in the longer term we really need to find a better way to define these, but without breaking BC, this is the best we can do.

technically there's no reason why the first reserved ID can't be used directly,
but allowing this would require special conditions in the unit tests, so this fix is easier.

auto incrementing IDs are a big pain and don't offer any obvious advantages.
In PM6, it's looking like using strings for type IDs directly will be the logical course of action
However, we can still get some benefit in PM5 from breaking the hard cycle here, and this makes it a bit less inconvenient to implement new things.